System, process and device for e-commerce transactions

ABSTRACT

Systems, devices and processes for electronic commerce payment processing using a handle and a mobile device with a mobile wallet application installed thereon. The handle may be used at a merchant website to process the electronic commerce payment for instead of providing payment information and/or personally identifiable information. That is, the handle may not include payment information and/or personally identifiable information.

CROSS REFERENCE TO RELATED APPLICATIONS

The applications claims priority to U.S. Provisional Application No.62/426,388 filed Nov. 25, 2016 and U.S. Provisional Application No.62/533,519 filed Jul. 17, 2017, the contents of which are herebyincorporated by reference.

FIELD

The improvements generally relate to the field of electronictransactions.

INTRODUCTION

Existing e-commerce and commerce workflows require customers to providepersonally identifiable login information and/or payment details to amerchant website or device to process payment for the transaction. Thismay pose security risks.

SUMMARY

In accordance with an aspect, there is provided a system of processingpayment for a transaction at an electronic wallet application on oraccessible by a mobile device. The system can have the electronic walletapplication having non-transitory computer-readable storage medium withcomputer-executable instructions for causing a processor of the mobiledevice to: authorize a user account of the electronic walletapplication; trigger the display of a confirmation request on a displayof the mobile device; provide a payment confirmation. The system canhave a payment server having non-transitory computer-readable storagemedium with computer-executable instructions for causing a processor ofthe payment server to: associate the user account with a first handlefor processing payment using the electronic wallet application; receivea payment request to process payment for an electronic commercetransaction for a merchant website, the payment request indicating thefirst handle, a merchant identifier and transaction data; process thepayment request to by verifying the user account associated with thefirst handle and the merchant identifier using a data repository, theuser account identifying the electronic wallet application; transmit theconfirmation request to the electronic wallet application, theconfirmation request including at least a portion of the transactiondata; receive the payment confirmation from the electronic walletapplication; transmit, over a secured channel, a payment security tokento a merchant server associated with the merchant website; and transmitan approval message to update the merchant website with paymentconfirmation notification.

In some embodiments, the electronic wallet application has thenon-transitory computer-readable storage medium with thecomputer-executable instructions for causing the processor of the mobiledevice to generate and transmit a registration request to associate theuser account with a first handle.

In some embodiments, the first handle is active to process a singlepayment request, wherein the payment server is configured to de-activatethe first handle after transmitting the payment security token.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the user account with the first handle for processingpayment using the electronic wallet application.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to receive a first paymentaccount, the first handle for processing payment using the first paymentaccount, and associate the first payment account with the first handle.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to: process a second registrationrequest to associate the user account with a second handle forprocessing payment using a second payment account; receive a secondpayment request to process payment for another electronic commercetransaction, the payment request indicating the second handle, themerchant identifier or another merchant identifier, and additionaltransaction data; process the payment request to determine the useraccount associated with the second handle; transmit a confirmationrequest including at least a portion of the additional transaction data;authorize the user account of the electronic wallet application; receiveanother payment confirmation from the electronic wallet application toprocess payment using the second payment account; transmit anotherpayment security token to the merchant server associated with themerchant identifier or another merchant server associated with the othermerchant identifier, the other payment security token for the secondpayment account; and transmit an approval message for another paymentconfirmation notification.

In some embodiments, the first handle is active to process a singlepayment request, wherein the method comprises de-activating the firsthandle after transmitting the payment security token.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to determine an encryption keyassociated with the merchant server and encrypting the payment securitytoken using the encryption key, the encrypted payment security fordecryption by the merchant server using a corresponding key.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to connect with a paymentsoftware development kit to: receive a mobile payment selection; promptfor the first handle at a form field; and transmit the first handle aspart of the payment request.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the user account with the first handle by verifyinguniqueness of the first handle by determining that the first handle isdifferent than all handles of a repository of handles stored on oraccessible by the payment server.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the user account with the first handle comprisesdetermining that the first handle is at least a minimum size.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to generate or identify a uniquehandle for the first handle, the unique handle being different than allactive handles of a repository of handles stored on or accessible by thepayment server.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to generate or identify a timesensitive handle for the first handle, the time sensitive handle beingactive for the electronic commerce transaction only for a defined periodof time.

In some embodiments, the transaction data comprises user data, whereinprocessing the payment request to determine the user account associatedwith the first handle comprises determining that the user data matchesstored data for the user account.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the first handle with the mobile device and the electronicmobile wallet, and process the payment request to determine the useraccount associated with the first handle by: determining the mobiledevice associated with the first handle, the mobile device beingassociated with the electronic wallet application.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to authorize the user account ofthe electronic wallet application, and receive the payment confirmationfrom the electronic wallet application comprise receiving a valid loginto the electronic wallet application.

In some embodiments, the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to transmit a transaction statusupdate for display on the merchant website to indicate that thetransaction is still pending until receipt of the payment confirmation.

In accordance with an aspect, there is provided a payment server forprocessing payment for a transaction. The payment server being connectedto an electronic wallet application on or accessible by a mobile device,the payment server having non-transitory computer-readable storagemedium with computer-executable instructions for causing a processor ofthe payment server to: associate a user account with a first handle forprocessing payment using the electronic wallet application; receive apayment request to process payment for an electronic commercetransaction at a merchant website, the payment request indicating thefirst handle, a merchant identifier and transaction data; process thepayment request to by verifying the user account associated with thefirst handle and the merchant identifier using a data repository, theuser account identifying the electronic wallet application; transmit theconfirmation request to the electronic wallet application, theconfirmation request including at least a portion of the transactiondata; receive the payment confirmation from the electronic walletapplication; transmit, over a secured channel, a payment security tokento a merchant server associated with the merchant website; and transmitan approval message to update the merchant website with paymentconfirmation notification.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to receive a registration request to associatethe user account with a first handle.

In some embodiments, the first handle is active to process a singlepayment request, wherein the payment server is configured to de-activatethe first handle after transmitting the payment security token.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to process a registration request to associatethe user account with the first handle for processing payment using theelectronic wallet application.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to receive a first payment account, the firsthandle for processing payment using the first payment account, andassociate the first payment account with the first handle.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to: process a second registration request toassociate the user account with a second handle for processing paymentusing a second payment account; receive a second payment request toprocess payment for another electronic commerce transaction, the paymentrequest indicating the second handle, the merchant identifier or anothermerchant identifier, and additional transaction data; process thepayment request to determine the user account associated with the secondhandle; transmit a confirmation request including at least a portion ofthe additional transaction data; authorize the user account of theelectronic wallet application; receive another payment confirmation fromthe electronic wallet application to process payment using the secondpayment account; transmit another payment security token to the merchantserver associated with the merchant identifier or another merchantserver associated with the other merchant identifier, the other paymentsecurity token for the second payment account; and transmit an approvalmessage for another payment confirmation notification.

In some embodiments, the first handle is active to process a singlepayment request, the payment server having non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to de-activate the first handle aftertransmitting the payment security token.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to determine an encryption key associated withthe merchant server and encrypting the payment security token using theencryption key, the encrypted payment security for decryption by themerchant server using a corresponding key.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to connect with a payment software developmentkit to: receive a mobile payment selection; prompt for the first handleat a form field; and transmit the first handle as part of the paymentrequest.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to process a registration request to associatethe user account with the first handle by verifying uniqueness of thefirst handle by determining that the first handle is different than allhandles of a repository of handles stored on or accessible by thepayment server.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to process a registration request to associatethe user account with the first handle comprises determining that thefirst handle is at least a minimum size.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to generate or identify a unique handle forthe first handle, the unique handle being different than all activehandles of a repository of handles stored on or accessible by thepayment server.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to generate or identify a time sensitivehandle for the first handle, the time sensitive handle being active forthe electronic commerce transaction only for a defined period of time.

In some embodiments, the transaction data comprises user data, thepayment server having non-transitory computer-readable storage mediumwith computer-executable instructions for causing the processor toprocess the payment request to determine the user account associatedwith the first handle comprises determining that the user data matchesstored data for the user account.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to process a registration request to associatethe first handle with the mobile device and the electronic mobilewallet, and process the payment request to determine the user accountassociated with the first handle by: determining the mobile deviceassociated with the first handle, the mobile device being associatedwith the electronic wallet application.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to authorize the user account of theelectronic wallet application, and receive the payment confirmation fromthe electronic wallet application comprise receiving a valid login tothe electronic wallet application.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to transmit a transaction status update fordisplay on the merchant website to indicate that the transaction isstill pending until receipt of the payment confirmation.

In accordance with an aspect, there is provided a method of processingpayment for a transaction using an electronic wallet application on oraccessible by a mobile device. The method involves, at a payment server,receiving a payment request to process payment for an electroniccommerce transaction at a merchant website, the payment requestindicating a first handle, a merchant identifier and transaction data;processing the payment request to determine the user account associatedwith the first handle, the user account identifying the electronicwallet application; transmitting a confirmation request to theelectronic wallet application, the confirmation request including atleast a portion of the transaction data; receiving a paymentconfirmation from the electronic wallet application; transmitting apayment security token to a merchant server associated with the merchantwebsite; and transmitting an approval message to update the merchantwebsite with payment confirmation notification.

In some embodiments, the method involves processing a registrationrequest to associate the user account with the first handle forprocessing payment using the electronic wallet application.

In some embodiments, the method involves processing the registrationrequest to associate the user account with the first handle forprocessing payment using the electronic wallet application comprises:receiving a first payment account, the first handle for processingpayment using the first payment account.

In some embodiments, the method involves, at the payment server,processing a second registration request to associate the user accountwith a second handle for processing payment using a second paymentaccount; receiving a second payment request to process payment foranother electronic commerce transaction, the payment request indicatingthe second handle, the merchant identifier or another merchantidentifier, and additional transaction data; processing the paymentrequest to determine the user account associated with the second handle;transmitting a confirmation request including at least a portion of theadditional transaction data; authorizing the user account of theelectronic wallet application; receiving another payment confirmationfrom the electronic wallet application to process payment using thesecond payment account; transmitting another payment security token tothe merchant server associated with the merchant identifier or anothermerchant server associated with the other merchant identifier, the otherpayment security token for the second payment account; and transmittingan approval message for another payment confirmation notification.

In some embodiments, the first handle is active to process a singlepayment request, wherein the method comprises de-activating the firsthandle after transmitting the payment security token.

In some embodiments, the method involves determining an encryption keyassociated with the merchant server and encrypting the payment securitytoken using the encryption key, the encrypted payment security fordecryption by the merchant server using a corresponding key.

In some embodiments, the method involves, at a payment softwaredevelopment kit, receiving a mobile payment selection; prompting for thefirst handle at a form field; and transmitting the first handle as partof the payment request.

In some embodiments, the method involves processing a registrationrequest to associate the user account with the first handle comprises:verifying uniqueness of the first handle by determining that the firsthandle is different than all handles of a repository of handles storedon or accessible by the payment server.

In some embodiments, the method involves processing a registrationrequest to associate the user account with the first handle comprisesdetermining that the first handle is at least a minimum size.

In some embodiments, the method involves generating or identifying aunique handle for the first handle, the unique handle being differentthan all active handles of a repository of handles stored on oraccessible by the payment server.

In some embodiments, the method involves generating or identifying atime sensitive handle for the first handle, the time sensitive handlebeing active for the electronic commerce transaction only for a definedperiod of time.

In some embodiments, the transaction data comprises user data, whereinprocessing the payment request to determine the user account associatedwith the first handle comprises determining that the user data matchesstored data for the user account.

In some embodiments, the method involves processing the registrationrequest to associate the first handle with the mobile device and theelectronic mobile wallet, wherein processing the payment request todetermine the user account associated with the first handle comprises:determining the mobile device associated with the first handle, themobile device being associated with the electronic wallet application.

In some embodiments, the method involves authorizing the user account ofthe electronic wallet application, and receiving the paymentconfirmation from the electronic wallet application comprise receiving avalid login to the electronic wallet application.

In some embodiments, the method involves transmitting a transactionstatus update for display on the merchant website to indicate that thetransaction is still pending until receipt of the payment confirmation.

In some embodiments, the method involves displaying a request forpayment confirmation including the portion of the transaction data orthe reference to the request package; receiving a transaction approvalto the request for payment confirmation; and transmitting thetransaction approval to the payment server.

In accordance with an aspect, there is provided a method of processingpayment for a transaction at an electronic wallet application on oraccessible by a mobile device, the method comprising: at the mobiledevice, authorizing a user account of the electronic wallet applicationon or accessible by the mobile device; receiving a first handleassociated with the user account; receiving a confirmation request atthe electronic wallet application, the confirmation request for apayment request to process payment for an electronic commercetransaction at a merchant website, the payment request indicating afirst handle, a merchant identifier, and transaction data; authorizingthe user account of the electronic wallet application; transmitting apayment confirmation to authorise the payment request to triggertransmission of a payment security token to a merchant server associatedwith the merchant website; and displaying an transaction message for thepayment confirmation.

In some embodiments, the method involves transmitting a registrationrequest to associate the user account with the first handle forprocessing payment using the electronic wallet application.

In some embodiments, the method involves processing the registrationrequest to associate the user account with the first handle forprocessing payment using the electronic wallet application comprises:receiving a first payment account, the first handle for processingpayment using the first payment account.

In some embodiments, the method involves, at the mobile device,authorizing the user account of the electronic wallet application on oraccessible by the mobile device; transmitting a second registrationrequest to associate the user account with a second handle forprocessing payment using a second payment account; receiving aconfirmation request for a second payment request to process payment foranother electronic commerce transaction, the payment request indicatingthe second handle, the merchant identifier or another merchantidentifier, and additional transaction data; authorizing the useraccount of the electronic wallet application; transmitting anotherpayment confirmation from the electronic wallet application to processpayment using the second payment account to trigger transmission ofanother payment security token to the merchant server associated withthe merchant identifier or another merchant server associated with theother merchant identifier, the other payment security token for thesecond payment account; and transmitting an approval message for anotherpayment confirmation notification.

In some embodiments, the first handle is active to process a singlepayment request and is de-activated after transmitting the paymentsecurity token.

In some embodiments, the method involves transmitting a registrationrequest to associate the user account with the first handle comprises:verifying uniqueness of the first handle by determining that the firsthandle is different than all handles of a repository of handles storedon or accessible by the payment server.

In some embodiments, the method involves transmitting a registrationrequest to associate the user account with the first handle comprisesdetermining that the first handle is at least a minimum size.

In some embodiments, the method involves generating or identifying aunique handle for the first handle, the unique handle being differentthan all active handles of a repository of handles.

In some embodiments, the method involves generating or identifying atime sensitive handle for the first handle, the time sensitive handlebeing active for the electronic commerce transaction only for a definedperiod of time.

In some embodiments, the method involves transmitting a registrationrequest to associate the first handle with the mobile device and theelectronic mobile wallet.

In some embodiments, the method involves authorizing the user account ofthe electronic wallet application, and receiving the paymentconfirmation from the electronic wallet application comprise receiving avalid login to the electronic wallet application.

In some embodiments, the method involves transmitting a transactionstatus update for display on the merchant website to indicate that thetransaction is still pending until receipt of the payment confirmation.

In accordance with an aspect, there is provided a method of processingpayment for a transaction using an electronic wallet application on oraccessible by a mobile device. The method involves, at a payment server,receiving a payment request to process payment for an electroniccommerce transaction from a merchant website, the payment requestindicating a user account identifier, a merchant identifier andtransaction data; processing the payment request to determine the useraccount associated with the user account identifier, the user accountidentifying the electronic wallet application; transmitting aconfirmation request to the electronic wallet application, theconfirmation request including at least a portion of the transactiondata; receiving a payment confirmation from the electronic walletapplication; and transmitting a payment package to a merchant serverassociated with the merchant website.

In some embodiments, the user account identifier is a unique handle.

In some embodiments, the user account identifier is payment code.

In some embodiments, the payment package is a payment security token.

In accordance with an aspect, there is provided a system of processingpayment for a transaction at an electronic wallet application on oraccessible by a mobile device. The system has the electronic walletapplication having non-transitory computer-readable storage medium withcomputer-executable instructions for causing a processor of the mobiledevice to: authorize a user account of the electronic walletapplication; trigger the display of a confirmation request on a displayof the mobile device; provide a payment confirmation. The system has apayment server having non-transitory computer-readable storage mediumwith computer-executable instructions for causing a processor of thepayment server to: associate the user account with a user accountidentifier for processing payment using the electronic walletapplication; receive a payment request to process payment for anelectronic commerce transaction at a merchant website, the paymentrequest indicating the user account identifier, a merchant identifierand transaction data; transmit the confirmation request to theelectronic wallet application, the confirmation request including atleast a portion of the transaction data; receive the paymentconfirmation from the electronic wallet application; transmit, over asecured channel, a payment package to a merchant server associated withthe merchant website; and transmit an approval message to update themerchant website with payment confirmation notification.

In some embodiments, the user account identifier is a unique handle.

In some embodiments, the user account identifier is payment code.

In some embodiments, the payment package is a payment security token.

In accordance with an aspect, there is provided a method of processingpayment for a transaction at an electronic wallet application on oraccessible by a mobile device. The method involves: authorizing a useraccount of the electronic wallet application; receiving a code, the codecomprising a reference to a request package, the request packageindicating transaction data, a customer account identifier, and amerchant identifier; transmitting the reference to a payment server;receiving a portion of the transaction data; displaying a request forpayment confirmation including the portion of the transaction data;receiving a transaction approval to the request for paymentconfirmation; and transmitting the transaction approval to the paymentserver.

In some embodiments, the method can involve receiving link approval tocreate a link between an electronic wallet application identifier forthe user account and the customer account identifier for subsequenttransactions; and transmitting the link approval and the walletapplication identifier.

In some embodiments, the method can involve receiving notification of anadditional transaction request and additional transaction data, theadditional transaction involving the customer account identifier and themerchant identifier; displaying an additional purchase request includingthe additional transaction data; receiving an additional transactionapproval to process payment; and transmitting the transaction approvalto the payment server.

In some embodiments, the method can involve verifying that the requestpackage is linked to the merchant identifier.

In some embodiments, the request package is encrypted using a first keylinked to the merchant and wherein the verifying comprises using asecond key linked to the merchant to decrypt the request package.

In some embodiments, the code comprises machine readable data as thereference to the request package. In some embodiments, the code isencrypted by a key linked to the merchant.

In some embodiments, the transaction approval comprises a selectedpayment type.

In some embodiments, the code is temporary and valid for a limited use.

In accordance with an aspect, there is provided a system of processingpayment for a transaction at an electronic wallet application on oraccessible by a mobile device. The system has the electronic walletapplication having non-transitory computer-readable storage medium withcomputer-executable instructions for causing a processor of the mobiledevice to: authorize a user account of the electronic walletapplication; receive a code, the code comprising a reference to arequest package, the request package indicating transaction data, acustomer account identifier, and a merchant identifier; transmit thereference to the request package to the payment server; receive aportion of the transaction data; display a request for paymentconfirmation including the portion of the transaction data or thereference to the request package; receive a transaction approval to therequest for payment confirmation; and transmitting the transactionapproval. The system has the payment server having non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing a processor of the payment server to: receive the referenceto the request package; transmit the reference to a cloud service;receive the request package from the cloud service; transmit the portionof the transaction data from the request package or the reference to therequest package; receive the transaction approval to the request forpayment confirmation from the mobile device; and transmit a paymentpackage to the cloud service, the payment package including thetransaction approval, the customer account identifier, and the merchantidentifier.

In some embodiments, the electronic wallet application havingnon-transitory computer-readable storage medium with computer-executableinstructions for causing the processor of the mobile device to: receivelink approval to create a link between an electronic wallet applicationidentifier for the user account and the customer account identifier forsubsequent transactions; and transmit the link approval and the walletapplication identifier.

In some embodiments, the electronic wallet application hasnon-transitory computer-readable storage medium with computer-executableinstructions for causing the processor of the mobile device to: receivenotification of an additional transaction request and additionaltransaction data, the additional transaction involving the customeraccount identifier and the merchant identifier; display an additionalpurchase request including the additional transaction data; receive anadditional transaction approval to process payment; and transmit thetransaction approval to the payment server.

In some embodiments, the electronic wallet application hasnon-transitory computer-readable storage medium with computer-executableinstructions for causing the processor of the mobile device to: verifythat the request package is linked to the merchant identifier.

In some embodiments, the request package is encrypted using a first keylinked to the merchant and wherein the electronic wallet application hasnon-transitory computer-readable storage medium with computer-executableinstructions for causing the processor of the mobile device to verifyusing a second key linked to the merchant to decrypt the requestpackage.

In some embodiments, the code comprises machine readable data as thereference to the request package.

In some embodiments, the code is encrypted by a key linked to themerchant.

In some embodiments, the transaction approval comprises a selectedpayment type.

In some embodiments, the code is temporary and valid for a limited use.

In some embodiments, receiving the transaction approval to the requestfor payment confirmation involves receiving a selected payment optionfrom a plurality of payment options.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing a processor of the payment server to: receive link approvalto create a link between an electronic wallet application identifier andthe customer account identifier for subsequent transactions; and createa link package with a link between the wallet application identifier andthe customer account identifier.

In some embodiments, the payment server has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing a processor of the payment server to: receive notificationof an additional transaction request and additional transaction data,the additional transaction involving the customer account identifier andthe merchant identifier; receive an additional transaction approval toprocess payment for the additional transaction; and transmit anadditional payment package to the cloud service, the payment packageincluding the additional transaction approval, the customer accountidentifier, and the merchant identifier.

In some embodiments, receiving the transaction approval to the requestfor payment confirmation comprises receiving a selected payment optionfrom a plurality of payment options.

In accordance with an aspect, there is provided a method of processingpayment for a transaction at a server interacting with an electronicwallet application on or accessible by a mobile device. The methodinvolves receiving a reference to a request package from the mobiledevice, the request package indicating transaction data, a customeraccount identifier, and a merchant identifier; transmitting thereference to a cloud service; receiving the request package from thecloud service; transmitting a portion of the transaction data from therequest package; receiving a transaction approval to a request forpayment confirmation from the mobile device; and transmitting a paymentpackage to the cloud service, the payment package including thetransaction approval, the customer account identifier, and the merchantidentifier.

In some embodiments, the method can involve receiving link approval tocreate a link between an electronic wallet application identifier andthe customer account identifier for subsequent transactions; andcreating a link package with a link between the wallet applicationidentifier and the customer account identifier.

In some embodiments, the method can involve receiving notification of anadditional transaction request and additional transaction data, theadditional transaction involving the customer account identifier and themerchant identifier; receiving an additional transaction approval toprocess payment for the additional transaction; and transmitting anadditional payment package to the cloud service, the payment packageincluding the additional transaction approval, the customer accountidentifier, and the merchant identifier.

In accordance with an aspect, there is provided a payment server having:a communication interface; and at least one processor configured to:receive a reference to a request package from the mobile device, therequest package indicating transaction data, a customer accountidentifier, and a merchant identifier; transmit the reference to a cloudservice;

receive the request package from the cloud service; transmit a portionof the transaction data from the request package; receive a transactionapproval to a request for payment confirmation from the mobile device;and transmit a payment package to the cloud service, the payment packageincluding the transaction approval, the customer account identifier, andthe merchant identifier.

In accordance with an aspect, there is provided a mobile device having:a communication interface; and at least one processor configured to:authorize a user and a payment option; receive a code, the codecomprising a reference to a request package, the request packageindicating transaction data, a customer account identifier, and amerchant identifier; transmit the reference to a payment server; receivea portion of the transaction data; display a request for paymentconfirmation including the portion of the transaction data; receive atransaction approval to the request for payment confirmation; andtransmit the transaction approval to the payment server.

In accordance with an aspect, there are provided systems, devices andprocesses for electronic commerce (e-commerce) payment processing usinga handle and a mobile device with a mobile wallet application installedthereon. The handle may be used at a merchant website to process theelectronic commerce payment for instead of providing payment informationand/or personally identifiable information. That is, the handle may notinclude payment information and/or personally identifiable information.

In accordance with an aspect, there is provided a payment server havinga communication interface; and at least one processor configured to:receive an electronic message from a software development kit at amerchant website including a first handle, the handle to process paymentfor an electronic commerce transaction, the handle linked to a mobiledevice; determine the mobile device linked to the handle; transmit arequest for confirmation of payment notification including summary datafor the electronic commerce transaction; receive an authorizationnotification in response to the request; and transmit a payment securitytoken to a merchant server linked to the merchant website.

In accordance with an aspect, there is provided a mobile device having acommunication interface; and at least one processor configured to:transmit an electronic message including a first handle linked to themobile device, the handle to process payment for an electronic commercetransaction; receive, from a server, a payment notification includingsummary data for the electronic commerce transaction; verifying log incredentials in response to an authorization request; display a requestfor confirmation of the payment notification; and send, to the server,the confirmation of the payment notification.

In accordance with an aspect, there is provided a mobile device having acommunication interface; and at least one processor configured to:receive a user configured first handle and link the first handle to themobile device; receive, from a server, a payment notification includingsummary data for the electronic commerce transaction; verifying log incredentials in response to an authorization request; display a requestfor confirmation of the payment notification; and send, to the server,the confirmation of the payment notification.

In accordance with an aspect, there is provided a mobile device having acommunication interface; and at least one processor configured to:transmit an electronic message including a first handle linked to themobile device, the handle to process payment for an electronic commercetransaction, the first handle generated automatically and having anactive time period; receive, from a server, a payment notificationincluding summary data for the electronic commerce transaction;verifying log in credentials in response to an authorization request;verifying the active time period of the first handle; display a requestfor confirmation of the payment notification; and send, to the server,the confirmation of the payment notification.

Many further features and combinations thereof concerning embodimentsdescribed herein will appear to those skilled in the art following areading of the instant disclosure.

DESCRIPTION OF THE FIGURES

Embodiments will now be described, by way of example only, withreference to the attached figures, wherein in the figures:

FIG. 1A is a diagram of an example system for e-commerce transactionsusing mobile devices;

FIG. 1B is a diagram of an example system for transactions using mobiledevices;

FIG. 2 is a diagram of an example workflow of a system for e-commercetransactions using mobile devices;

FIG. 3 is a diagram of another example workflow of a system fore-commerce transactions using mobile devices;

FIG. 4 is a diagram of an example computing device of a system fore-commerce transactions using mobile devices;

FIG. 5 is a diagram of an example system for e-commerce transactionsusing mobile devices;

FIG. 6 is a diagram of an example system for e-commerce transactionsusing mobile devices;

FIG. 7 is a diagram of another example workflow of a system fortransactions using mobile devices according to some embodiments;

FIG. 8 is a diagram of another example workflow of a system fortransactions using mobile devices according to some embodiments;

FIG. 9 is a diagram of another example workflow of a system fortransactions using mobile devices according to some embodiments; and

FIG. 10 is a screenshot of an interface of a system for transactionsusing mobile devices according to some embodiments.

FIG. 11 is a screenshot of an interface of merchant website of a systemfor transactions using mobile devices according to some embodiments.

FIG. 12 is a screenshot of an interface of merchant website of a systemfor transactions using mobile devices according to some embodiments.

FIG. 13 is a screenshot of an interface of a mobile device of a systemfor transactions using mobile devices according to some embodiments.

FIG. 14 is a screenshot of an interface of a mobile device of a systemfor transactions using mobile devices according to some embodiments.

FIG. 15 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 16 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 17 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 18 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 19 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 20 is a screenshot of an interface of a mobile device and merchantwebsite of a system for transactions according to some embodiments.

FIG. 21 is a screenshot of an interface of a merchant website of asystem for transactions according to some embodiments.

FIG. 22 is a screenshot of an interface of a system for transactionsaccording to some embodiments.

FIG. 23 is a screenshot of an interface of a merchant website of asystem for transactions according to some embodiments.

FIG. 24 is a screenshot of an interface of a mobile device and merchantwebsite of a system for transactions according to some embodiments.

FIG. 25 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 26 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 27 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 28 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 29 is a screenshot of an interface of a mobile device of a systemfor transactions according to some embodiments.

FIG. 30 is a screenshot of an interface of a merchant website of asystem for transactions according to some embodiments.

FIG. 31 is a flowchart of a method for transactions according to someembodiments.

FIG. 32 is a flowchart of a method for transactions according to someembodiments.

DETAILED DESCRIPTION

Embodiments described herein provide a system that enables transactionsusing mobile devices to benefit from increased security. Thetransactions can be in-store transactions or e-commerce transactions,for example. The transaction can be referred to as electronictransactions as they involve electronic devices, such as a mobiledevices, secure channels and servers, for example.

FIG. 1A is a diagram of an example system 100 for e-commercetransactions using mobile devices. The system 100 includes a paymentserver 110, and mobile (or electronic) wallet application 104 residingon a mobile device 114. In some embodiments, the system 100 includes amerchant website 106 for access by a consumer 112 for e-commercetransactions. The merchant website 106 is associated with a merchantserver 108 to process payments for the e-commerce transaction. Thepayment server 110 and the mobile wallet application 104 can includelogic or programming code to automatically trigger control actions.Components of the system 100 can be coupled using one or more networks114. The network 114 (or multiple networks) is capable of carrying data.The network 114 can involve wired connections, wireless connections, ora combination thereof. In some embodiments, components of the system 100can exchange data by way of a cloud service.

In some embodiments, the system 100 enables transaction and paymentprocessing using mobile devices 114 to benefit from increased security.In some embodiments, the system 100 enables transactions using a user(or customer) account identifier, such as machine readable handle orpayment code. In some embodiments, the system 100 enables transactionsusing a payment code readable by wallet application 104. The paymentcode can include a reference to a request package or payment requestthat includes data about a transaction. For example, the request packagecan include transaction data, a customer account identifier, and amerchant identifier. The customer account identifier may be received bya merchant website 106, for example. The system 100 can link thecustomer account identifier to a wallet application identifier for awallet application 104 of mobile device 114 to streamline paymentprocess for subsequent transactions.

In some embodiments, the system 100 enables transactions using a handle.In some embodiments, the system 100 enables e-commerce transactionsusing a unique name (as an example handle) to be inserted in ane-commerce checkout web page (e.g. in a credit card number field) of amerchant website 106, which triggers control commands to a financialinstitution system to route a payment confirmation message to aregistered mobile device. In some embodiments, the unique name or handlecan be input into a merchant device at point-of-sale in a merchantlocation.

In some embodiments, the system 100 enables transactions using a mobiledevice 114 with a payment or electronic wallet application 104 toprovide increased security. To process payment for the transaction, aninterface of a merchant website 106 can display an option to “pay withsecure mobile system”. This may involve an interface with a modifiedcheckout web page at a merchant website 106 that includes a user accountidentifier, such as a payment code (e.g. QR code), for example. Insteadof providing or indicating any payment information at the checkout webpage of a merchant website 106, the customer can use the user accountidentifier (such as the payment code, for example) to process thetransaction using a mobile device 114. The user account identifierfunctions to link or associate a payment account with a specifictransaction such that the payment account is used to provide paymentfrom a customer to a merchant for the transaction. The payment accountmay indicate sensitive financial data that may trigger security issuesif it is provided at the merchant website. The user account identifiermay not indicate sensitive financial data such that it can be providedat the merchant website (e.g. entered in a form field or displayed forcapture) without triggering the same security issues as the paymentaccount. The backend payment server 110 can link or associate the useraccount identifier with the payment account in order to process paymentfrom the customer to the merchant. For example, malicious software maymonitor or merchant website 106 in order to capture information enteredor displayed on the merchant website 106. In such a case the malicioussoftware can only capture the user account identifier which may not besufficient to process unauthorized transactions without requiringadditional actions or information. The user account identifier cancontain information about the requested transaction and can be encryptedusing a key for the merchant, for example. The customer payment cardinformation is not exposed to the merchant, and the merchant does nothave to store it. Further, the user does not have to provide any paymentinformation on a merchant's website 106.

For example, the user account identifier can be a unique handle that acustomer can input into the merchant website at a form field. As anotherexample, user account identifier can be a payment code that can bedisplayed at the merchant website. For example, the customer can thentake an image of a QR code displayed on the webpage with the customer'smobile device 114 having a camera and a wallet application 104. Thecustomer can securely access the wallet application 104 on the mobiledevice 114 using an authentication process (e.g. by logging-in toapplication, providing a fingerprint and/or other biometric associatedwith the login). The QR code can contain information about the requestedtransaction which can be encrypted using a key for the merchant, forexample. The mobile application 114 can decrypt or decode the data inthe code. A message with a confirmation request can be displayed at themobile device 114 to confirm the purchase and select a method of payment(e.g. credit card, bank card, value card). Upon confirming theselection, the mobile device 114 sends data to the associated financialinstitution payment server 110 in the form of tokenized datarepresenting the selected payment method. The financial institutionpayment server 110 routes any necessary data to a merchant server 108 toprocess payment. The customer payment card information is not exposed tothe merchant, and the merchant does not have to store it. Further, theuser does not have to provide any payment information on a merchant'swebsite 106.

In some embodiments, the system includes a software development kit(SDK) 102. The merchant website 106 is configured using the SDK 102 toprovide a payment option, such as “pay with secure system”, and uponselection triggers secure payment workflows according to embodimentsdescribed herein. Accordingly, the SDK 102 can be used to modify themerchant website 106 to indicate the payment option and trigger paymentworkflow with mobile device 114. For example, the SDK 102 can configurethe merchant website 106 to display a code as part of the paymentworkflow. As another example, the SDK 102 can configure the merchantwebsite 106 to display a field to receive a handle or code as part ofthe payment workflow.

For example, selection of the secure payment option can request orprompt the consumer 112 to enter an identifier code or handle at themerchant website 106. In some embodiments, the consumer 112 previouslyregisters the handle using the mobile wallet application 104 residing ona mobile device 114, for example. The wallet application 104 and server110 exchange data communications to link or associate the handle with amobile device 114 that has the mobile wallet application 104 installedthereon. For example a user account profile may store data relating toone or more handles, one or more payment accounts, one or moreelectronic wallet applications 104, one or more mobile devices 114,transaction history data, and other information about the user. Thepayment server 110 can store multiple user account profiles in arepository that can be accessed in order to determine the mobile walletapplication 104 associated with a particular handle.

Upon receiving the handle, the merchant website 106 sends the handle tothe payment server 110, which looks up the associated mobile device 114(and the mobile wallet application 104) using the repository of useraccount profiles. The payment server 110 sends a push notification tothe mobile device 114 (and the mobile wallet application 104), thenotification indicating that a request for a payment transaction wasreceived from the merchant website 106. The notification may containinformation about the transaction (e.g. purchase summary) and redirectthe notification to the mobile wallet application 104. In someembodiments, the notification may prompt or encourage the consumer 112to launch the mobile wallet application 104 to display furtherinformation about the requested transaction. In some embodiments, thenotification can include code to automatically launch the mobile walletapplication 104. Information about the transaction could beautomatically requested by the mobile wallet application 104 in securecommunication with the payment server 110, or the information about therequested transaction may be pushed to the wallet application 104 uponopening it.

The consumer 112 may be asked to confirm the payment request through themobile wallet application 104 by a variety of methods. The mobile device114 and the electronic wallet application 104 can authorize the userlinked to the user account. Example authentication methods includeentering a password, fingerprint or other biometric data, or byauthenticating using a previously provisioned secure token stored on themobile device 114, for example.

Handles may be made of a variety of characters or symbols, and be ofdifferent lengths. There may be a minimum length in some embodiments.The handle can be generated or configured by the consumer 112. Whengenerated by the consumer 112, the system 100 can verify the handle andits uniqueness against a repository of assigned handles. The handle canalso be generated by the mobile wallet application 104 or server 110. Inthe case of temporary handles, the system 100 may generate an availablehandle that is not presently active, such as a numerical string oflimited length (e.g. 6 digits), to allow for ease of entry into therespective checkout form field by the consumer 112.

The consumer 112 may register a different handle for each mobile device114 the user wishes to use for e-commerce. The consumer 112 may registera different handle for different payment accounts or products in themobile wallet application 104. The consumer 112 may also assigntemporary handles in some embodiments. Instead of permanentlyregistering a mobile device 114 with the system 100, the consumer 112may temporarily assign a handle to the mobile device 114, through themobile wallet application 104, for example, in advance of a transaction.The handle may be for a single or limited number of uses, or limited toa particular time period. That is the handle may be a temporary handle.Accordingly, the user account profile can link a first handle with afirst payment account and can link a second handle with a second paymentaccount. The user can provide the first handle a merchant website 106 toprocess payment with the first payment account. The user can provide thesecond handle to the merchant website 106 to process payment with thesecond payment account. In this way the user has flexible options forpayment in a secured manner.

Prior to sending the request to the mobile device 114 of the consumer112, the payment server 110 may verify that information related to theconsumer 112 provided to the merchant website 106 matches storedinformation associated with the handle. For example the consumer 112 mayalso provide their date of birth along with the handle. The user accountprofile can store the date of birth and the handle. The payment server110 can verify the received date of birth and the received handle by wayof a comparison to the data in the user account profile.

In some embodiments, the consumer 112 may only provide the handle to themerchant website 106 instead of any payment card information and/orpersonally identifiable information. This may enhance security aspayment information is not received at the merchant website 106. Whenapproving the transaction through the mobile wallet application 104, theconsumer 112 can select a method of payment through the mobile walletapplication 104 to pay for the transaction, thereby allowingnon-traditional methods of payment supported by the mobile walletapplication 104, but not typically supported by merchants. This alsolimits the sharing of payment information with the merchant website 106.As noted, different handles may be associated with different paymentaccounts as another option to use different payment accounts.

As another example, selection of the secure payment option can promptthe display of a code at the merchant website 106. The code may beanother example of the user account identifier in that the code islinked to a user account profile. In some embodiments, the consumer 112can process the transaction using the mobile device 114 by capturing thecode at the merchant website 106 instead of providing any payment cardinformation and/or personally identifiable information to the merchantwebsite 106. This may enhance security as payment information is notreceived at the merchant website 106. When approving the transactionthrough the mobile wallet application 104, the consumer 112 can select amethod of payment through the mobile wallet application 104 to pay forthe transaction, thereby allowing non-traditional methods of paymentsupported by the mobile wallet application 104, but not typicallysupported by merchants. This limits the sharing of payment informationwith the merchant website 106 and provides flexible payment options.

In some embodiments, the payment approval may require more time toprocess, such as when a non-standard method of payment is selected orthe mobile device 114 is not readily accessible, for example. The server110 can be configured to communicate to the merchant website 106 thatthe transaction is still pending. The merchant website 106 may thenpresent a suitable page to the user saying that the transaction requestwas received and that the user will be notified when the transaction isapproved. In the event that further confirmations or modifications arerequired to the payment method, a component of the system 100 may send asuitable notification to the mobile device 114 to open the walletapplication 104. The notification may request such further user actionas is necessary through the wallet application 104. For example, therequest may prompt for input or capture of the code displayed on themerchant website 106. A traditional e-commerce transaction might timeoutwaiting for payment approval, but the system 100 can provide forasynchronous payment approvals.

In some embodiments, there may be multiple payment transaction requestspending for approval or confirmation by consumer 112. Where multiplepayment transaction requests are pending, the transaction requests maybe displayed in a list or one after another in the mobile walletapplication 104, to be viewed prior to approving any of them. Eachtransaction request may be associated with a different code displayed ondifferent merchant websites 106. In some embodiments, a link between anelectronic wallet application identifier for the user account and thecustomer account identifier for subsequent transactions can remove therequirement of scanning or capturing the code and the transactionrequest can be automatically triggered by selecting the option to paywith the system 100.

As noted, in some embodiments, the system 100 enables transactions usinga code that links the wallet application 104 and the mobile device 114to the merchant server 106. The payment server 110 can register amerchant server 108 to provide an encryption key, which may be assignedby a financial institution system, for example. To process payment forthe transaction, the merchant website 106 can provide an option to “paywith secure system”. This may present a modified checkout page at themerchant website 106 with a displayed code (e.g. QR code), for example.The code can link the merchant server 108 to the wallet application 104.Instead of providing any payment information on the merchant website106, the consumer 112 can use the code to process the transaction. Forexample, the consumer 112 can then take an image or photo of a QR codedisplayed on the website 106 with a camera of the mobile device 114. Theconsumer 112 can securely access the application 104 on the mobiledevice 114 (e.g. by logging-in to application or providing a fingerprintor other biometric associated with the login) to add another level ofsecurity.

The code can contain information about the requested transaction and canbe encrypted using a merchant key generated with the financialinstitution during the registration process, for example. The mobileapplication 104 can decrypt the data in the code. A message with aconfirmation request can be displayed in the mobile application 104 sothat the consumer 112 can confirm the purchase, and then select a methodof payment within the mobile application 104 (e.g. credit card, bankcard, value card). Upon confirming the selection, the mobile device 114sends data to the associated financial institution servers in the formof tokenized data representing the selected payment method. Thefinancial institution routes any necessary data to a merchant server toprocess payment. The merchant website receives a confirmation thatpayment was received. In this way, the payment card information is notexposed to the merchant (e.g. merchant website 106, merchant server106), and the merchant does not have to store it. Further, the consumer112 does not have to provide any payment information on a merchant'swebsite 106.

In some embodiments, instead of a QR code displayed on the merchantwebsite 106, there may be a field for the consumer 112 to enteridentification details, such as a phone number or handle, on themerchant website 106 to indicate an electronic address to send thepayment confirmation request. The merchant server 106 can send a textmessage to that phone number with the same encrypted data that wouldhave been in the QR code, for example. The wallet application 104 can beconfigured to listen for such text messages formatted in a specific way(e.g. using the key generated and exchanged during registration of themerchant) and automatically bring up the confirmation screen in theapplication. This is another example of an account identifier that cantrigger payment processing using the mobile device 114.

In some embodiments, the e-commerce checkout can be performed as part ofthe merchant website 106 which can also refer to a merchant applicationon the same mobile device 114 as the wallet application 104. Theconfirmation for payment can also be performed on the same mobile device114. The merchant website 106 can present the encrypted data in themerchant website 106 in a format that would be directly readable orroutable to the wallet application 104. For example, the encrypted datacan be a formatted string or QR code with a button to send locally tothe wallet application 104.

Optionally, the consumer 112 can choose to link the customer's tokenizedpayment information with the merchant server 108. In this way, the tokencould be stored by the merchant server 108 for use multiple times,without the consumer 112 having to re-confirm on the mobile device 114.In some embodiments, an identifier for the mobile device 114 may bestored by the merchant server 106 for later use. During a futuretransaction, only confirmation and payment information from thatidentified mobile device 114 can be accepted by the merchant website 106and merchant server 108 for checkouts involving the account of theconsumer 112. Changing the link can require routing a confirmation tothat mobile device 114 as well. In the event of a lost or broken mobiledevice 114 after linking, the consumer 112 can contact the paymentserver 110 to purge or delete all of the links of the consumer 112associated with merchants.

In some embodiments, if no link is stored between merchant server 106and mobile device 114, then it may be possible for any device andtokenized payment method represented on the mobile wallet 104 on thatdevice 114 to be used to confirm and make the payment.

FIG. 1B shows an example system 100 with a merchant device 116. Thesystem 100 can assist with “in-person” transactions at a merchant'sphysical store, for example. The merchant store has a merchant device116 to connect with a mobile device 114 to process the transaction. Themerchant device 116 can use near field communication (NFC) or Bluetoothtechnology to exchange data (including the code) with the walletapplication 104, for example. The merchant device 116 can connect withthe merchant server 108 to implement the workflows described herein withreference to the merchant website 106, for example. Accordingly, thesystem 100 is not limited to e-commerce transactions and be used toprocess in store transactions in some embodiments. Further detailsrelating to in store transactions are provided herein in relation toFIG. 9, for example. In some examples, the merchant device 116 isoperable to display a form field in order to receive a handle from thecustomer in the store. Accordingly both the handle and the QR code cantrigger payment processing in the mobile device 114 in the store.

FIG. 2 shows an example of a system 100 and workflow 200 for e-commercetransactions using mobile devices. In some embodiments, the system 100uses a handle selected or configured by a consumer 112 for thee-commerce transaction at the merchant website 106. The consumer 112uses the mobile device 114 to access the merchant website 106 to shopand, after they are done shopping 202, trigger an e-commerce transactioncheck out process. The check-out process may include an interface withform fields for receiving information to process the payment transactionfor e-commerce. The consumer 112 uses the mobile device 114 or anothercomputing device to send control commands using SDK 102 to select amobile payment transaction 204 option from a list of payment options inthe interface with form fields.

The consumer 112 creates an account with a payment server 110 toconfigure a user handle linked to a mobile device 114 and walletapplication 104. The payment server one 110 stores the user handle, anidentifier for mobile device 114, and an identifier for the walletapplication 104 in the user account profile. As noted, the paymentserver 110 stores the user account profiles in a repository in order todetermine the user account associated with a handle received frommerchant website 106. When a selected mobile payment transaction 204option is detected, the server 110 transmits 206 control commands toprompt for the custom user handle. The SDK 102 transmits 208 controlcommands for input data at a form field in the interface in response tothe prompt for the custom user handle. The server 110 receives the inputdata for the handle. The server 110 confirms the user handle anddetermines 210 the corresponding mobile device 114 and walletapplication 104 (e.g. linked to the handle during the registrationprocess) using the repository of user account profiles. As noted, theuser account profile includes an identifier for the mobile device 114and an identifier for the wallet application 104 in order to transmit aconfirmation request for display on the mobile device 114. That is, theidentifier for the mobile device 114 and the identifier for the walletapplication 104 indicate an address or pointer for transmission of theconfirmation request. The server 110 transmits 212 a notification to themobile device 114 and wallet application 104 with payment details andrequests confirmation by displaying a confirmation request on a displayof the mobile device 114. The mobile device 114 and wallet application104 transmits a confirmation message 216 to the server 110 to confirmthe mobile payment transaction. The consumer 112 responds 214 to thenotification to confirm the transaction at mobile device 114 and walletapplication 104 by signing into their profile using the mobile walletapplication 104, for example. The wallet application 104 is operable toregister and authenticate the consumer 112 (using a login, uniqueidentifier, and password for example) prior to providing access topayment services and profile information, including the handle. Themobile device 114 or wallet application 104 may serve one user ormultiple consumers 112. At 218, the payment server 110 sends a securedpayment token for the confirmed payment amount with other payment datato a merchant server 108 to complete the e-commerce mobile paymenttransaction.

The consumer 112 downloads or installs the mobile wallet application 104to their mobile device 114. The consumer 112 uses the mobile walletapplication 104 for registration of the payment checkout service toconfigure a customer profile. The consumer 112 can use the mobile walletapplication 104 to select a unique handle, which will be associated totheir customer profile and devices 114. The mobile wallet application104 can connect to the payment server 110 for the registration process.The mobile wallet application 104 can provide its identifier along withthe unique handle during the registration process in order to link itsidentifier and the unique handle to the customer account profile. Whenthe consumer 112 visits a merchant browser website 106 with the SDK 102checkout service, the customer 112 can be prompted to enter the selectedunique handle at the time of payment. The data entry can send anotification to the mobile device 114 linked to the consumer 112profile. When the consumer 112 is authenticated they can review the nameof the merchant and the payment amount for the transaction as part of anotification or message, and select their funding account/product. Insome embodiments, the payment account is linked to the unique handle atthe customer account profile. In other embodiments, the customer canselect a payment account at the time of providing confirmation ofpurchase and the handle can be linked to the customer account generally.A payment token is sent to a merchant server 108 to process payment forthe transaction. The consumer 112 can view the confirmed payment on themerchant browser 106. That is, the merchant website 106 can display theconfirmed payment.

FIG. 3 shows an example of a system 100 and workflow 300 for e-commercetransactions using mobile devices 114. In some embodiments, the system100 uses a unique time sensitive handle for the e-commerce transactionat the merchant website 106. The unique time sensitive handle can begenerated by the wallet application 104 or server 110 in someembodiments. The unique time sensitive handle is linked to the useraccount in the user account profile. The consumer 112 uses a mobiledevice 114 to access the merchant website 106 for e-commerce and, afterthey are finished 202 electronic shopping, the consumer 112 can triggeran e-commerce transaction check out process. The consumer 112 uses themobile device 114 to send control commands using SDK 102 for a mobilepayment transaction 204. When a mobile payment transaction 204 isdetected, the server 110 sends control commands to prompt for the userhandle 206. The consumer 112 enters the unique time sensitive handle ata form field of an interface on merchant website 106. The merchantwebsite 106 or SDK 102 transmits the unique time sensitive handlepayment server 110. The payment server 110 determines the mobile device114 and/or wallet application 104 linked to the unique time sensitivehandle using the repository of user account profiles. The user accountprofile associates the unique time sensitive handle with an identifierfor mobile device 114 and/or an identifier for wallet application 104 todetermine where to transmit the confirmation request to. The paymentserver 110 transmits the confirmation request to the associated walletapplication 104 and mobile device 114.

The consumer 112 signs into their account or profile, at 230, using amobile device 114 and the wallet application 104 to receive a uniquetime sensitive handle. The wallet application 104 generates the uniquetime sensitive handle. The unique time sensitive handle can be temporaryand expires after a configured time duration or expiration period, suchas 10 minutes, 15 minutes, 1 hour, and so on. The SDK 102 sends controlcommands, at 232, to prompt for the handle. The SDK 102 receives inputdata for the handle in response to the prompt and transmits, at 234, theinput data for the handle to the server 110. The server 110 receives theinput data for the handle and determines 210 the corresponding mobiledevice 114 and wallet application 104. That is, the server 110determines 210 the mobile device 114 and wallet application 104 linkedto the input data for the handle. The server 110 transmits 212 anotification to the mobile device 114 and wallet application 104 withpayment details and requests confirmation. The mobile device 114 andwallet application 104 transmit a confirmation message 216 to the server110 to confirm the mobile payment transaction. The consumer 112 responds214 to the notification to confirm the transaction 214 at the mobiledevice 114 and wallet application 104 by signing into their profile oraccount using the mobile wallet application 104. The server 110 sends218 a payment token for the confirmed payment amount with other paymentdata to merchant server 108 to complete the e-commerce transaction.

The consumer 112 visits a merchant website 106 running the SDK 102checkout service. The SDK 102 prompts the consumer 112 via merchantbrowser website 106 to enter the time sensitive generated handle at thetime of payment. The consumer 112 opens and signs into the walletapplication 104 on a mobile device 114. Once authenticated the consumer112 will use the wallet application 104 on a mobile device 114 torequest a generated time sensitive handle associated with a selectedfunding account or product. That is, different accounts or products canbe associated with different handles. The consumer 112 enters thegenerated handle into the merchant browser website 106 running the SDK102. The merchant website 106 sends a request to the server 110 for apayment token to process payment for the e-commerce transaction. Theserver 110 sends a payment token to the merchant server 108 to processpayment for the e-commerce transaction. The consumer 112 obtainsconfirmation on the merchant website 106 that the payment was processed.

The embodiments of the devices, systems and methods described herein maybe implemented in a combination of both hardware and software. Theseembodiments may be implemented on programmable computers, each computerincluding at least one processor, a data storage system (includingvolatile memory or non-volatile memory or other data storage elements ora combination thereof), and at least one communication interface.

FIG. 4 is a schematic diagram of a computing device 400 that may be usedto implement aspects of the server 110, mobile device 114 or otherdevice used to access the merchant website 106. As depicted, thecomputing device 400 includes at least one processor 402, memory 404, atleast one I/O interface 406, and at least one network interface 408.

Each processor 402 may be, for example, any type of general-purposemicroprocessor or microcontroller, a digital signal processing (DSP)processor, an integrated circuit, a field programmable gate array(FPGA), a reconfigurable processor, or any combination thereof.

Memory 404 may include a suitable combination of any type of computermemory that is located either internally or externally such as, forexample, random-access memory (RAM), read-only memory (ROM), compactdisc read-only memory (CDROM), electro-optical memory, magneto-opticalmemory, erasable programmable read-only memory (EPROM), andelectrically-erasable programmable read-only memory (EEPROM),Ferroelectric RAM (FRAM) or the like.

Each I/O interface 406 enables the computing device 400 to interconnectwith one or more input devices, such as a keyboard, mouse, camera, touchscreen and a microphone, or with one or more output devices such as adisplay screen and a speaker.

Each network interface 408 enables the computing device 400 tocommunicate with other components, to exchange data with othercomponents, to access and connect to network resources, to serveapplications, and perform other computing applications by connecting toa network (or multiple networks) capable of carrying data. Program codeis applied to input data to perform the functions described herein andto generate output information and discernible effects. The outputinformation is provided to one or more output devices.

FIG. 5 is a diagram of an example system for e-commerce transactionsusing mobile device 104. The mobile wallet application 114 configures ahandle with the payment server 110. The ecommerce application 506receives input data for the handle. The ecommerce application 506transmits the input data for the handle and purchase order details tothe payment server 110. The purchase order details include a merchantidentifier and purchase amount. The payment server 110 validates thehandle, merchant identifiers, and purchase order details. The paymentserver 110 transmits a payment token over a secured channel to merchantserver 108. The payment server 110 can encrypt the payment token usingmerchant certificates. The payment server 110 transmits a notificationto the mobile wallet application 114 on a mobile device 104. Thenotification includes ecommerce information (merchant identifier, orderdata, payment data). The mobile wallet application 114 on the mobiledevice 104 confirms the payment to process the transaction.

The electronic wallet application 114 has non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing a processor of the mobile device to implement set ofoperations. The electronic wallet application 114 operates to authorizea user account at the mobile device 104. The electronic walletapplication 114 operates to trigger the display of a confirmationrequest on a display of the mobile device 104. The electronic walletapplication 114 operates to provide a payment confirmation on a displayof the mobile device 104.

The payment server 110 has non-transitory computer-readable storagemedium with computer-executable instructions for causing a processor ofthe payment server one 110 to implement a set of operations. The paymentserver 110 operates to associate the user account with a first handlefor processing payment using the electronic wallet application 114. Thepayment server 110 operates to receive a payment request to processpayment for an electronic commerce transaction at a merchant website106. The payment request indicates the first handle, a merchantidentifier and transaction data. As noted, the user has the option toconfigure multiple handles linked to different wallets 114 or paymentaccounts in the account profile. The first handle refers to one of theconfigured handles.

The payment server 110 operates to process the payment request to byverifying the user account associated with the first handle and themerchant identifier using a data repository. That is, the payment server110 uses the data repository of account profiles to identify the accountlinked to the received handle. The account profile associates handleswith various wallets 114 and payment accounts. The user accountidentifies the electronic wallet application 114 linked to the receivedhandle.

The payment server 110 operates to transmit the confirmation request tothe electronic wallet application 114. The confirmation request includesat least a portion of the transaction data. The electronic walletapplication 114 triggers the display of the confirmation request on adisplay of the mobile device 104.

The payment server 110 operates to receive the payment confirmation fromthe electronic wallet application 114. In response, the payment server110 operates to transmit, over a secured channel, a payment securitytoken to a merchant server 108 associated with the merchant website 106.The payment security token can be encrypted using a key link to themerchant server 108. The merchant server 108 can decrypt the encryptedpayment security token using a corresponding key.

The payment server 110 operates to transmit an approval message toupdate the merchant website 106 with payment confirmation notification.

In some embodiments, electronic wallet application 114 has thenon-transitory computer-readable storage medium with thecomputer-executable instructions for causing the processor of the mobiledevice 104 to generate and transmit a registration request to associatethe user account with a first handle. The registration request can alsoindicate a payment account for example. That is, the user can configurea handle linked to its account using a registration process.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the user account with the first handle for processingpayment using the electronic wallet application 114.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to receive a first paymentaccount, the first handle for processing payment using the first paymentaccount, and associate the first payment account with the first handle.This enables the user to associate different payment accounts withdifferent handles to provide a flexible yet secure payment process. Theelectronic wallet application 114 can store different payment accountsthat can be linked to different handles in the user account profile.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to: process a second registrationrequest to associate the user account with a second handle forprocessing payment using a second payment account; receive a secondpayment request to process payment for another electronic commercetransaction, the payment request indicating the second handle, themerchant identifier or another merchant identifier, and additionaltransaction data; process the payment request to determine the useraccount associated with the second handle; transmit a confirmationrequest including at least a portion of the additional transaction data;authorize the user account of the electronic wallet application; receiveanother payment confirmation from the electronic wallet application toprocess payment using the second payment account; transmit anotherpayment security token to the merchant server associated with themerchant identifier or another merchant server associated with the othermerchant identifier, the other payment security token for the secondpayment account; and transmit an approval message for another paymentconfirmation notification. That is, different handles can be used toprocess payments using different payment accounts. The registrationprocess enables a user to link different handles to the differentpayment accounts. The electronic wallet 114 can manage different paymentaccounts that can be selected to create the link to different handles.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to determine an encryption keyassociated with the merchant server 108 and encrypting the paymentsecurity token using the encryption key. The encrypted payment securitytoken for decryption by the merchant server 108 using a correspondingkey. The payment server 110 can have different keys for differentmerchant servers 108.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to connect with a paymentsoftware development kit 102 to receive a mobile payment selection atthe merchant website 106; prompt for the first handle at a form fielddisplayed at the merchant website 106; and transmit the first handle aspart of the payment request.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the user account with the first handle by verifyinguniqueness of the first handle by determining that the first handle isdifferent than all handles of a repository of handles stored on oraccessible by the payment server 110. In this way, the payment server110 ensures uniqueness of the handles so that a given handle does notmap to multiple user accounts.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the user account with the first handle comprisesdetermining that the first handle is at least a minimum size. Thepayment server 110 may require that the first handle be at least of athreshold size.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to generate or identify a uniquehandle for the first handle, the unique handle being different than allactive handles of a repository of handles stored on or accessible by thepayment server 110. In some embodiments, each handle can have anassociated status such as active or inactive. Before changing aninactive status to an active status, the payment server 110 can check toensure that handle is unique as compared to all other active handles.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to generate or identify a timesensitive handle for the first handle. The time sensitive handle beingactive for the electronic commerce transaction only for a defined periodof time. After the expiration of the time period, the handle may changefrom an active status to an inactive status for example.

In some embodiments, the transaction data comprises user data. Thepayment server 110 can process the payment request to determine the useraccount associated with the first handle by determining that the userdata matches stored data for the user account. For example, thetransaction data may include an address or phone number. The paymentserver 110 can match the address or phone number to stored address orphone number in the user account profile.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to process a registration requestto associate the first handle with the mobile device 104 and theelectronic mobile wallet 114, and process the payment request todetermine the user account associated with the first handle by:determining the mobile device 104 associated with the first handle. Thepayment server 110 can have an account profile to associate the mobiledevice 104 with the electronic wallet application 114.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to authorize the user account ofthe electronic wallet application 114, and receive the paymentconfirmation from the electronic wallet application 114 by receiving avalid login to the electronic wallet application 114.

In some embodiments, the payment server 110 has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to transmit a transaction statusupdate for display on the merchant website 106 to indicate that thetransaction is still pending until receipt of the payment confirmation.As noted, there may be a delay between the time of the payment requestis triggered at the merchant site 106 and the time when the payment isprocessed using the mobile device 104 and the merchant server 108. Inorder to avoid looking at the processes timed out, the merchant site 106can update its display to indicate a still pending status to providefeedback to the user.

FIG. 6 is a diagram of an example system for e-commerce transactionsusing mobile devices. The mobile wallet application 114 provides inputdata to the payment server 110. The one-time handle is generated by thepayment server 110. In some embodiments, the one-time handle is randomlygenerated by the payment server 110. The mobile wallet application 114provides the one-time handle to the consumer 112 for the e-commercetransaction. A consumer 112 can enter the one-time handle to anecommerce application 506. The ecommerce application 506 transmits thehandle and purchase order details to payment server 110. The purchaseorder details include a merchant identifier and purchase amount. Theecommerce application 506 can include the merchant website 106 in someembodiments. The payment server 110 validates the handle and purchaseorder details. The payment server 110 transmits a payment token over asecured channel to the merchant server 108. The payment server 110 canencrypt the payment token using merchant certificates. The paymentserver 110 transmits a notification to mobile wallet application 114.The notification includes ecommerce information (merchant identifier,order data, payment data). In some embodiments, the first handle isactive to process a single payment request. The payment server 110 isconfigured to de-activate the first handle after transmitting thepayment security token. That is, the first handle can be a single usehandle. In some embodiments, the first handle is active to process asingle payment request, wherein the method comprises de-activating thefirst handle after transmitting the payment security token.

FIG. 7 is a diagram of another example workflow of a system 100 fortransactions using mobile devices according to some embodiments. Thisexample workflow can relate to an initial usage of the code to link aconsumer account of the merchant with a particular wallet application104 (e.g. to create a link between an electronic wallet applicationidentifier for the user account and the customer account identifierregistered with merchant server 108 for subsequent transactions). Thecode can be an example user account identifier in that the server 110can use the code to locate the corresponding user account and associatedwallet application 114. In this example embodiment, the system 100includes a device that is configured to display a merchant website 106.The device can be different than the mobile device 114 or the device maybe the same as mobile device 114, for example. In some embodiments, thedevice is accessible by mobile device 114 with the wallet application104 for at least part of the workflow to capture the code, for example.In some embodiments, the mobile device 114 is the device and is operableto display the merchant website 106, such as by a mobile browser or amobile merchant application. Accordingly, the merchant website 106 canrefer to a merchant mobile application. The consumer 112 wants to make apurchase at the merchant website 106 and may have an account registeredwith the merchant server 108 (e.g. customer account identifier andpassword, for example). In this example embodiment, the payment for thetransaction can be approved or confirmed using the mobile device 114with the wallet application 104.

The merchant server 108 registers with the payment server 110 in orderto generate and receive an encryption key unique to the merchant. Forexample, the encryption key can include a private key for the merchantand a public key for the financial institution. The encryption key isexchanged between the payment server 110 and the merchant server 108 inorder to secure data. The financial institution can use a correspondingpublic key to decrypt data protected using the merchant private key. Insome embodiments, the encryption key is not provided to the merchantwebsite 106 and the mobile device 114 so that it cannot be interceptedby an unauthorized party by phishing or another malicious interventiontechnique.

In some embodiments, the user requests to purchase one or more productsand/or services at a merchant website 106. The user can initiate apayment process for the products and/or services at the merchant website106. The user can select a payment option for purchasing the productsand/or services using the mobile wallet application 104. The paymentoptions may include different payment card options, for example. In someembodiments, the user can provide an account name (e.g. customer accountidentifier) to the merchant website 106 as part of a sign in or log inprocess. This can provide traceability and some level of security. Also,this can enable creation of a link between the wallet application 104and the merchant website 106 or server 108 for subsequent use, as willbe described in relation to FIG. 8. For example, system 100 can create alink between an electronic wallet application identifier for the useraccount and the customer account identifier for subsequent transactions.In some embodiments, the workflow could be modified to have an anonymousconsumer (e.g., user is not logged into merchant).

At 702, the merchant server 108 creates a request package which issecured by the encryption key and transmits the request package to themerchant website 106. The merchant server 108 can create a requestpackage in response to receiving a selection at the merchant website 106to pay for goods and/or services using a mobile device 114 and thewallet application 104, such as an electronic button to “pay with mobilewallet”. The “request package” can include different data elements suchas: description of goods and/or services, item amount, tax amount, totalamount, merchant identifier, merchant account information (includingcustomer account identifier), and so on. Additionally, the requestpackage can include information about the consumer or user on file fromthe merchant, such as phone number, address, and so on. The additionalinformation regarding the consumer or user can be confirmed by afinancial institution (providing the financial account to the consumerand/or operating payment server 110) to provide additional confidencelevel to the merchant associated with the merchant website 106. Forexample, if the user is purchasing products or services with the paymenttotal over a threshold amount then verification may be implemented bythe financial institution. For example, if the consumer selects to havethe product delivered, the merchant server 108 can provide the user'saddress on file to the financial institution as part of the requestpackage, and the financial institution can confirm if the addressmatches with user's address on file with the financial institution.

The following provides a non-limiting example request package:

{ amt = “464.35”; cur = CAD; desc = “Weekend Getaway at Royal YorkHotel”; expires = 1498047986457; firstName = John; id =“01ad4ac5-28ac-4ed4-834c-c5e50e74db66”; infoReq = ( payment,       email,        address,        pushNotification        ); jti =“b4c67aea-2601-4069-b54c-e1cbab0164fc”; lastName = Doe; merchantId =3879203; merchantName = “Expedia”; sub = “John Doe”; tax = “60.37”;total = “524.72”; userAccountId =“7c2b727d-a4d0-44e2-b6c0-5c0753fa3454”; }

The request package can also be used in the process referred to hereinin relation to the handle. In some embodiments, the request package canbe signed with a merchant private key. This can help ensure that therequest package is generated by merchant's back-end server 108 with itsprivate key. In some embodiments, the request package is encrypted bythe merchant server 108 with a financial institution's public key toensure that only the financial institution with the private key candecrypt the contents of the request package.

At 704, the merchant website 106 provides the request package to a cloudservice 110 for provision to the payment server 110. In someembodiments, the request package is encrypted using the encryption codeso that an unauthorized party cannot access the request package.

At 706, the merchant website 106 browser session displays a code withmachine-readable data, such as a QR code, for example. The code can beencrypted using an encryption key that is exchanged between the paymentserver 110 and the merchant server 108. The code contains a reference tothe request package so that the request package can be retrieved usingthe reference. The reference and the request package are used to processthe transaction. The payment information is not provided to the merchantwebsite 106 and the merchant server 108 so that the sensitiveinformation cannot be accessed by phishing, hacking or other maliciousunauthorized access. Further, the merchant website 106 and the merchantserver 108 do not receive the payment information and are not requiredto store the sensitive payment information.

For example, the code can be a QR code that contains an URL to therequest package. The reference can be inside the URL. In someembodiments, this URL can be for temporary one time use only. In someembodiments, when the request package is delivered to the cloud service120, in response the cloud service 120 generates a one-time use URL(including the reference) and QR code containing that URL. In someembodiments, the QR code is not encrypted as it is a one-time use URLwhich provides some protection.

The following is an example of QR code content:https://d2x1a3hyfe6kmg.cloudfront.net/app-e/rb/w/r?r=c71783fe-8295-4208-a472-64b855600af6.In this example, “c71783fe-8295-4208-a472-64b855600af6” can be atemporary one time use “reference” to the request package. In anembodiment where a mobile browser on a mobile device 114 is used toaccess the merchant website 106 (e.g. on the same device 114 as thewallet application 104, the same link can be used to deeplink from themerchant browser session 106 to the wallet application 104.

At 708, the wallet application 104 scans or reads the code displayed onthe merchant website 106 to obtain the reference to the request package.For example the wallet application 105 can interact with the camera ofthe mobile device 114 to capture an image of the QR code displayed onthe merchant website 106.

At 710, the wallet application 104 submits the reference to the paymentserver 110. At 712, the payment server 110 retrieves the request packagefrom the cloud service 120 using the reference. In some embodiments, thepayment server 110 can store request packages which can be retrievedusing corresponding references. The payment server 110 can transmittransaction data from the request package to the wallet application 104.At 714, the wallet application 104 displays a confirmation request forthe transaction (e.g. request for payment confirmation) using a portionof the transaction data, such as the total amount and the merchantidentifier, for example. The consumer 112 approves the purchase on thewallet application 104 by accepting or approving the confirmationrequest (e.g. transaction approval) using the mobile device 114. Thetransaction approval can include a selected payment type, such asselection of a specific credit card, value card, or other paymentoption.

As noted, there may be an authentication process required at the mobiledevice 114 in order to access the wallet application 104 and approve therequest for payment confirmation (e.g. confirmation request for thetransaction). The authentication process can involve biometricauthentication such as a thumbprint, fingerprint, eye or facialauthentication process. This may provide another layer of security forthe transaction as only authenticated consumers can provide thetransaction approval at the wallet application 104.

In some embodiments, at 716, the consumer 112 can approve the creationof a link between the wallet application 104 and the merchant accountassociated with the consumer 112. For example, the wallet application104 can receive link approval to create a link between an electronicwallet application identifier for the user account and the customeraccount identifier for subsequent transactions. In such embodiments, thestep of receiving or capturing the code at the wallet application 104may not be required as the link can be used to determine the customeraccount identifier or the electronic wallet application identifier forsubsequent transactions. The merchant server 108 or the payment server110 can include a database linking consumer account identifiers towallet application identifiers for efficient processing of subsequenttransactions.

At 718, the payment server 110 transmits, to the cloud service 120, apayment package and a wallet link indication if the consumer 112approved the linking. The following provides a non-limiting examplepayment package:

paymentPackage = { requestPackageId =“01ad4ac5-28ac-4ed4-834c-c5e50e74db66”,paymentToken        =          “e7dad004-770f-49b5-9615-1fe4093b8680-9D461700E7D38EFD3012EF67B16F801F58251E453CE66CD5625FA4B498B2D005”,paymentTokenExpiry = “2017-03-14T15:37:25” timestamp =“2017-03-14T15:36:21”, amount = “524.72”, currency = “CAD” }

Before linking, a database record 122 of the database managed by themerchant server 108 (or payment server 110) does not link the accountname to a particular wallet application 104. After approving thelinking, a database record 124 of the database managed by the merchantserver 108 (or payment server 110) links the account name to the walletapplication 104. The database record 124 identifies the walletapplication 104 using a unique identifier. The unique identifier for thewallet application 104 can be generated at payment server 110. At thepayment server 110, the connection between merchant's user account (thiscould be an account number or unique identifier generated from merchant)and the unique identifier for the wallet application 104 can bemaintained. The payment server 110 can identify if the merchant's useraccount has the unique identifier for the wallet application 104associated with it or not. In some embodiments, the merchant server 108can add the wallet application identifier to the request package forsubsequent transactions. In some embodiments, the payment server 110 cando the look up for the wallet application identifier.

Examples of additional information or data fields stored in records ofthe database at merchant server 108:

linked-to-wallet: Yes or No

Wallet-identifier: W23498374894

Example of additional information or data fields stored in records ofthe database at payment server 110:

Linked-merchant-id: M38923

Linked-merchant-user account id: 9381738495

Link-created-at: 2017-03-04 14:05:23 Wallet-identifier: W23498374894

Wallet-app-uuid: 211FA29B-0103-4BCE-8875-4994CD269A07Wallet-push-notification-id:c4d983b172ea7b83aa35e22f3b3efd7db637c521c0be0154d6a86443be6b70b7

At 720, the cloud service 120 provides a notification of the transactionand the merchant website 106 browser session resumes to display thetransaction confirmation. Accordingly, an initial purchase with themerchant can require the scan of the code at the mobile device 114 tocreate the link between the consumer account name of the merchant andthe wallet application 104. Subsequent purchases might not require thecode scanning step.

FIG. 8 is a diagram of another example workflow of system fortransactions using mobile devices 104 according to some embodiments.This example embodiment relates to a workflow for subsequent usage afterthe initial link has been created between the consumer account name ofthe merchant and the particular wallet application 104. As noted,subsequent purchases might not require the code scanning step. Instead,the workflow may proceed directly to the confirmation request at thewallet application 104. The merchant server 108 or the payment server110 can access relevant data records using the link between theelectronic wallet application identifier for the user account and thecustomer account identifier for these subsequent transactions. Forexample, the merchant server 108 can locate the electronic walletapplication identifier in the database using the customer accountidentifier. The electronic wallet application identifier is used toidentify the wallet application 104 in order to prompt or triggerdisplay of the request for payment confirmation at the walletapplication 104. If the consumer 112 switches mobile devices 114 orreinstalls the wallet application 104 then they may need to rescan thecode to create the link between the consumer account name of themerchant and the wallet application 104 as there may be a differentelectronic wallet application identifier. The electronic walletapplication identifier is used to identify a wallet application 104 inorder to deliver data and/or commands to the wallet application 104,such as requests for payment confirmation.

At 802, the merchant server 108 creates a request package and transmitsit to the merchant website 106. The request package can include thecustomer account identifier and/or the electronic wallet applicationidentifier. At 804, the merchant website 106 provides the requestpackage to the cloud service 120. At 806, the merchant website 106browser session optionally displays indicia to trigger the securepayment process. The merchant website 106 browser session optionallydisplays the code, such as the QR code for example. The code contains areference to the request package. For subsequent purchases, after anapproval of the linking is received, a push notification can beautomatically sent out to the wallet application 104 without capture ofthe QR code. This can streamline the workflow. However, in someembodiments, the merchant website 106 can display the QR code in casethe push notification is not delivered (e.g., user changed to a newphone, so the previous wallet indicator may be out of date).

At 808, the consumer 112 activates or selects the indicia to trigger thesecure payment process using the wallet application 104. Selection ofthe indicia can also include an indication that this is a returningconsumer 112 and a subsequent purchase by a consumer 112 who haspreviously linked their account name with the merchant to a particularwallet application 104. The merchant website 106 browser session invokesa payment request notification API (such as provided by SDK 102, forexample) at the cloud service 120. At 812 and 814, the cloud service 120requests the payment server 110 to send a push notification to requestpayment confirmation with the request package. The request package canindicate the consumer account identifier, for example. The paymentserver 110 can retrieve the electronic wallet application identifierfrom the stored data record of the merchant database using the linkbetween the consumer account identifier (or merchant account) and theelectronic wallet application identifier (for the wallet application104). At 814, the payment server 110 sends a push notification to thewallet application 104 using the electronic wallet applicationidentifier. The push notification can include a request for paymentconfirmation including a reference to the request package. Thenotification can also include a portion of transaction data (e.g.merchant, amount). The payment server 110 can maintain associationbetween wallet identifier and link to merchant account.

At 816, the wallet application 104 receives the request detail anddisplays the request for payment confirmation for approval. At 818, theconsumer 112 approves the confirmation request for the transaction byselecting indicia at the wallet application 104 and/or providing inputdata to the mobile device 114 (e.g. biometric verification). The walletapplication 104 receives the transaction approval to the request forpayment confirmation. At 820, the payment server 110 transmits thepayment package (including the transaction approval) to the cloudservice 120. At 822, the merchant website 106 receives the paymentpackage and/or the transaction approval. The merchant website 106resumes the browser session to finalize the transaction.

FIG. 9 is a diagram of another example workflow of system fortransactions using mobile devices according to some embodiments. Asnoted, in some embodiments the consumer 112 can be face-to-face with amerchant for the transaction. For example, the consumer 112 can be inthe physical store of the merchant and this may be referred to as anin-store transaction. In some embodiments the merchant may not havecredit card processing equipment or other point-of-sale terminalcapabilities. However, the merchant can have a merchant device 116 withthe capability to exchange data with the wallet application 104. Forexample the merchant device 116 can have NFC and Internet capabilitiesto exchange data with the wallet application 104 and cloud service 120.The mobile device 114 and the wallet application 104 can be registeredwith the merchant to receive push notifications such as requests forpayment confirmations for the transactions. The merchant device 116 canbe registered to receive push notifications from the cloud server 120.The consumer 112 has a mobile device 114 with a wallet application 104installed thereon. The consumer 112 wants to make a purchase from themerchant in person.

At 902 the merchant uses the merchant device 116 to initiate the paymentprocess for the transaction. The merchant device 116 creates a requestpackage and transmits the request package to the cloud service 120. At904, the consumer 112 taps (e.g. brings it within a pre-defined range orlocation) its mobile device 114 on the merchant device 116 or otherwiseinteracts with the merchant device 116. The merchant device 116transmits a request reference identifier to the mobile device 114. At906, the wallet application 104 retrieves the request package from thecloud service. In some embodiments, the steps can be implemented by theconsumer 112 scanning a code displayed on the merchant device 116 usingthe wallet application 104 and mobile device 114. At 908, the walletapplication 104 displays a request for payment confirmation, which isconfirmed by the consumer 112 using the mobile device 114. The walletapplication 104 receives a transaction approval to the displayed requestfor payment confirmation. At 910 and 912 the payment server 110 createsa payment package for provision to the cloud service 120. At 914, thecloud service 120 sends the push notification with a referenceidentifier for the payment package to the merchant device 116. At 916,the merchant device retrieves the payment package from the cloud service120. The payment for the purchase transaction is complete. In someembodiments, the merchant can have an account with the payment server110. The payment request can be directed to the merchant account in realtime or periodically such as daily, weekly or monthly.

FIGS. 10 to 30 are screenshots of different aspects of a system fortransactions using mobile devices according to some embodiments.

FIG. 10 is a screenshot of an interface for wallet application 104. Theinterface includes a form of form fields and corresponding field values.Example form fields include username, device token, merchant,notification options, and so on. The interface can be used to configurethe wallet application 104 to process payments for specific merchantsand merchant user accounts (e.g. consumer or user accounts registeredwith the merchant). The form can include selectable values to populatefield values corresponding to the different form fields. The interfacemay be accessible after authorization by the wallet application 104,such as by biometric authentication.

FIG. 11 is a screenshot of an interface for a merchant website 106. Theinterface includes selectable indicia 1102 to trigger the paymentprocess using the wallet application 104. The interface can also includea summary of payment details regarding a product or service offered by amerchant website 106.

FIG. 12 is a screenshot of an interface for a merchant website 106. Theinterface includes selectable indicia 1102 to trigger the paymentprocess using the wallet application 104. The interface can also includea summary of payment details regarding a product or service offered bythe merchant website 106. The interface can also include a form field toreceive a phone number or other identifier for the mobile device 114along with selectable indicia 1104 to send a message to the phone numberor identifier for the mobile device 114. The message can indicatedetails of the transaction for notification or confirmation. The messagecan also include a code that can be entered into the wallet application104 as part of the payment process. The interface can include a code1106 readable by the wallet application 104 as part of the paymentprocess. The interface can also indicate time remaining to complete thetransaction. The code 1106 can be created using the keys exchangedbetween the payment server 110, the merchant server 108 or the merchantwebsite 106. The code 1106 can be encrypted using the keys for security.

FIG. 13 is a screenshot of an interface for the mobile device 114including an icon 1302 to trigger the wallet application 104.

FIG. 14 is a screenshot of an interface of the mobile device 114 andwallet application 104 with indicia 1402 to authenticate a user usingbiometric authentication, such as a fingerprint for example. This can bean example authorization of a user account at mobile device 114.

FIG. 15 is a screenshot of an interface of the wallet application 104with visual representations of one or more payment accounts such as bankaccount, credit card account, and so on. The wallet application 104enables selection of a payment account for a particular transaction. Thewallet application 104 enables the addition of additional paymentoptions for transactions. The wallet application 104 enables the removalof payment options. Accordingly, the wallet application 104 enablesusers to add, remove, and update payment options for transactions. Asnoted herein, the interface with different payment accounts can be usedto link or associate a handle with a particular payment account.

FIG. 16 shows an interface 1602 for the merchant website 106 and anotherinterface 1604 for the wallet application 104. The interface 1604 forthe wallet application 104 includes an imaging component 1606 to capturean image of the code 1106 displayed on the merchant website 106. Theimaging component 1606 enables the wallet application 104 toautomatically capture or receive the code 1106. The interface 1604 forthe wallet application also includes a form field for code type 1608 anda form field for code content 1610. In some embodiments, the walletapplication 104 includes a form field to receive a code in other waysand capturing an image is just one example.

FIG. 17 shows an interface for the wallet application 104 with aconfirmation request 1702 to confirm a purchase option for payment ofthe transaction. The confirmation request 1702 can be used to select apurchase option at the wallet application 104. The confirmation request1702 can include information regarding the merchant, the goods orservices, and the total payment amount.

FIG. 18 shows an interface for the wallet application 104 with aconfirmation request 1802 to confirm payment for the transaction usingthe selected purchase option. The confirmation request 1802 can be usedto approve payment at the wallet application 104. The confirmationrequest 1802 can include information regarding the merchant, the goodsor services, and the total payment amount. The confirmation request 1802can include an option to select a different purchase option.

FIG. 19 shows an interface for the wallet application 104 with a linkrequest 1902 to link the wallet application 104 to the merchant useraccount (e.g. the customer account registered with the merchant website106). The link enables subsequent purchases from the merchant website106 using the wallet application 104 without requiring the initial stepof reading the code using the mobile device 114.

FIG. 20 shows an interface 2002 for the merchant website 106 and anotherinterface 2004 for the wallet application 104. The interface 2004 forthe wallet application indicates a purchase confirmation for thetransaction. The interface 2002 for the merchant website 106 alsoindicates a purchase confirmation for the transaction.

FIG. 21 shows an interface for the merchant website 106 that includes apayment confirmation code 2102 and a device token identifier 2104indicating the wallet application 104 used to process the payment. Theinterface also includes an indication that a confirmation message hasbeen sent to a particular address.

FIG. 22 is a screenshot of an interface for the wallet application 104.The interface includes a form of form fields and corresponding fieldvalues. Example form fields include username, device token, merchant,notification options, and so on. The interface can be used to configurethe wallet application 104 to process payments for specific merchantsand merchant user accounts (e.g. consumer or user accounts registeredwith the merchant). The form can include selectable values to populatefield values corresponding to the different form fields. The interfacemay be accessible after authorization by the wallet application 104,such as by biometric authentication. The interface indicates that thedevice token identifier for the wallet application 104 is linked to themerchant website 106 or the merchant server 108. Accordingly, the walletapplication 104 can be used for subsequent purchases at the merchantwebsite 106 without requiring the initial step of receiving the code atthe wallet application 104.

FIG. 23 is a screenshot of an interface for a merchant website 106. Theinterface includes selectable indicia 1102 to trigger the paymentprocess using the wallet application 104. The interface can also includea summary of payment details regarding a product or service offered bythe merchant website 106.

FIG. 24 shows an interface 2402 for the merchant website 106 and anotherinterface 2404 for the wallet application 104. The interface 1604 forthe wallet application 104 includes a confirmation request 2406 toapprove payment for the transaction. The interface 2404 does not have toinclude an imaging component 1606 to capture an image of the code 1106displayed on the merchant website 106 as the link is already createdbetween the wallet application 104 and the merchant website 106.

FIG. 25 shows an interface for the wallet application 104. The interfacefor the wallet application 104 includes a confirmation request 2502 toapprove payment for the transaction. The interface does not have toinclude an imaging component 1606 to capture an image of the code 1106displayed on the merchant website 106 as the link is already createdbetween the wallet application 104 and the merchant website 106.

FIG. 26 is a screenshot of an interface of a mobile device 114 and thewallet application 104 with indicia 2602 to authenticate a user usingbiometric authentication, such as a fingerprint for example.

FIG. 27 shows an interface for the wallet application 104 with aconfirmation request 2702 to confirm a purchase option for payment ofthe transaction. The confirmation request 2702 can be used to select apurchase option at the wallet application 104. The confirmation request2702 can include information regarding the merchant, the goods orservices, and the total payment amount.

FIG. 28 shows an interface for the wallet application 104 with aconfirmation request 2802 to confirm payment for the transaction usingthe selected purchase option. The confirmation request 2802 can be usedto approve payment at the wallet application 104. The confirmationrequest 2802 can include information regarding the merchant, the goodsor services, and the total payment amount. The confirmation request 2802can include an option to select a different purchase option.

FIG. 29 shows an interface for the wallet application 104 with apurchase approval 2902 for the transaction using the selected purchaseoption. The user can continue to shop for goods or services at themerchant website 106 for subsequent purchases.

FIG. 30 shows an interface for the merchant website 106 that includes apayment confirmation code 3002 and a device token identifier 3004indicating the wallet application 104 used to process the payment. Theinterface also includes an indication that a confirmation message hasbeen sent to a particular address.

FIG. 31 is a flowchart of a method 3100 for transactions according tosome embodiments. The method 3100 can be implemented at the paymentserver 110, for example.

At 3102, the payment server 110 receives a payment request to processpayment for an electronic commerce transaction from a merchant website106. The payment request indicate a user account identifier, a merchantidentifier and transaction data. The user account identifier can be ahandle or a code, for example. The payment server 110 can receive thehandle from a form field of the merchant website 106 as the user accountidentifier. The payment server 110 can receive a code as part of arequest package as the user account identifier.

At 3104, the payment server 110 processes the payment request todetermine the user account associated with the user account identifier.The user account identifies the electronic wallet application 114. Thepayment server 110 can use the user account identifier to determine auser account profile from multiple profiles stored in a repository. Theprofile can include the user account identifier along with an identifierfor the electronic wallet application 114.

At 3106, the payment server 110 transmits a confirmation request to theelectronic wallet application 114. The confirmation request includes atleast a portion of the transaction data. The electronic walletapplication 114 is configured to automatically display the confirmationrequest on a display of the mobile device 104 in order to receiveconfirmation from the user after it was authorized.

At 3108, the payment server 110 receives a payment confirmation from theelectronic wallet application 114. For example, the confirmation requestmay indicate the merchant identifier along with a purchase total for thetransaction for approval by the user. The user can approve theconfirmation request by selecting a selectable indicia which triggerstransmission of the payment confirmation from the wallet application 114to the payment server 110.

At 3110, the payment server 110 transmits a payment package to amerchant server 108 associated with the merchant website 106. Thepayment server 110 transmits the payment package directly to themerchant server 108 over a secure channel. That way, if there ismalicious software listening at the merchant website 106 the paymentdata is not transmitted there but instead goes directly to the merchantserver 108 which may be in a more secure location. The payment packagecan be a payment security token, for example.

FIG. 32 is a flowchart of a method 3200 for transactions according tosome embodiments. The method 3200 can be implemented at the walletapplication 114 or mobile device 104.

At 3202, the wallet application 114 or mobile device 104 can authorize auser account. The authorization can be a login or by way of biometricverification for example.

At 3204, the wallet application 114 or mobile device 104 can receive afirst handle associated with the user account. The handle can bereceived by way of a registration process where a user can select aunique handle to be linked to a payment account. The handle can bereceived from the payment server 110 as a temporary handle, for example.

At 3206, the wallet application 114 or mobile device 104 can receive aconfirmation request from the payment server 110. The confirmationrequest can indicate a merchant and transaction data such as a paymentamount along with one or more items related to the purchase. Theconfirmation request relates to a payment request to process payment foran electronic commerce transaction at a merchant website 106 or store.The payment request can indicate a first handle, a merchant identifier,and transaction data.

At 3208, the wallet application 114 or mobile device 104 can authorizethe user account of the electronic wallet application 114.

At 3210, the wallet application 114 or mobile device 104 can transmit apayment confirmation to authorise the payment request to triggertransmission of a payment security token from the payment server 110 toa merchant server 108 associated with the merchant website. That is, thepayment confirmation can include program instructions to control thepayment server 110 to generate a payment security token to process thepayment.

Throughout the foregoing discussion, numerous references will be maderegarding servers, services, interfaces, portals, platforms, or othersystems formed from computing devices. It should be appreciated that theuse of such terms is deemed to represent one or more computing deviceshaving at least one processor configured to execute softwareinstructions stored on a computer readable tangible, non-transitorymedium. For example, a server can include one or more computersoperating as a web server, database server, or other type of computerserver in a manner to fulfill described roles, responsibilities, orfunctions.

Embodiments described herein may enhance security as payment informationis not required at the merchant website 106 or other third partye-commerce platforms. Further, embodiments described herein may enablemultiple consumers 112 to engage in e-commerce using the same browser toaccess the merchant website 106 and mobile device 114. For example,different consumers 112 can use different usernames, wallet applications104, and handles to process payments for e-commerce transactions usingthe same browser to access merchant website 106. Further, differentconsumers 114 can log into the same mobile wallet application 104 toaccess their respective profile or account and associated notificationsor confirmations. Mobile devices 114 can be from different providers,for example.

Embodiments described herein may enable e-commerce payment transactionusing a code readable by the wallet application 104 and may enablesubsequent payment transactions using a link between the walletapplication 104 and the merchant website 106. For example, the code canbe generated using encryption keys exchanged between the merchant and afinancial institution. The code can be displayed on the interface of themerchant website 106. The server 110 maps the code to the merchant useraccount and the merchant server 108 or merchant website 106. The mobiledevice 104 may be configured for biometric verification. Once verifiedthen data can be exchanged between the wallet application 104, paymentserver 110, and merchant server 108 to process the payment.

Embodiments described herein may enable e-commerce payment transactionsusing a handle selected by the consumer 112. For example, this may be apre-set or configured handle within the mobile wallet application 104.The handle is entered into a form field of an interface of the merchantwebsite 106 and this process may not require a password or other paymentinformation for improved security. The server 110 maps the handle to amobile device 104 operated by the consumer 112. The mobile device 104may be configured for biometric verification. Once verified, a token isexchanged between wallet application 104, payment server 110, andmerchant server 108 to process the payment. The handle can relate tomulti-users and the handle can map to any enabled mobile device 104(e.g. mobile device 104 with the wallet application 114 installedthereon).

Embodiments described herein may enable e-commerce payment transactionsusing a time sensitive handle generated by the server 110 or mobilewallet application 114. The consumer 112 may not have set up a handle atthe wallet application 114. Instead, when the consumer 112 signs intothe mobile wallet application 114 it generates a time sensitive handleto enter into the e-commerce website. The handle may also be a securetoken in some embodiments.

Embodiments described herein enable a consumer 112 and mobile walletapplication 104 to disable the handle option, such as for an indefiniteor definite time period. For example, if the consumer 112 is travellingthey are able to disable the use of the handle while they are away forpeace of mind.

In some embodiments, the payment server 110 receives a handle and atransaction summary of the purchase from merchant website 106 topopulate notification for the mobile device 104 and mobile walletapplication 114. The payment server 110 transmits a payment token to themerchant server 108 to process payment for the e-commerce transaction.The payment server 110 interacts with the mobile wallet application 114to trigger the payment process. The merchant server 108 processespayment using the token and then sends a confirmation or notification tothe merchant website 106 to display confirmation screen. The paymentserver 110 uses the handle to identify the corresponding mobile device104 and mobile wallet application 114. That is, the handle may be linkedto an identifier for the mobile device 104 and an identifier for themobile wallet application 114. The payment process can occur inreal-time. In some embodiments, the merchant website 106 may be accessedusing mobile device 114 using a mobile browser or may be part of anapplication residing on a mobile device 114 or another device.

In some embodiments, the handle may be used to share other types of dataor information (in addition or instead of payment data) between thepayment server 110 and merchant website 106. For example, the handle maybe linked to other types of data or information such as address details,email, phone; and so on to share other types of data or informationbetween the payment server 110 and merchant website 106. The data mayhave an inherent level of trustworthiness as it is provided by thepayment server 110 which may be a trusted data source.

In some embodiments, the purchase order may be saved by the merchantwebsite 106 for later processing and payment. This enables anasynchronous payment approval process. If the consumer 112 cannot enterthe handle right away into the merchant website 106 then the merchantwebsite 106 can store the purchase order for later approval. In someembodiments, the merchant website 106 uses a call-back uniform resourcelocator to poll an address of the payment server 110 where the paymentauthorization is provided.

Various example embodiments are described herein. Although eachembodiment represents a single combination of inventive elements, allpossible combinations of the disclosed elements include the inventivesubject matter. Thus if one embodiment comprises elements A, B, and C,and a second embodiment comprises elements B and D, then the inventivesubject matter is also considered to include other remainingcombinations of A, B, C, or D, even if not explicitly disclosed.

The term “connected” or “coupled to” may include both direct coupling(in which two elements that are coupled to each other contact eachother) and indirect coupling (in which at least one additional elementis located between the two elements).

The technical solution of embodiments may be in the form of a softwareproduct. The software product may be stored in a non-volatile ornon-transitory storage medium, which can be a compact disk read-onlymemory (CD-ROM), a USB flash disk, or a removable hard disk. Thesoftware product includes a number of instructions that enable acomputer device (personal computer, server, or network device) toexecute the methods provided by the embodiments.

The embodiments described herein are implemented by physical computerhardware, including computing devices, servers, receivers, transmitters,processors, memory, displays, and networks. The embodiments describedherein provide useful physical machines and particularly configuredcomputer hardware arrangements. The embodiments described herein aredirected to electronic machines and methods implemented by electronicmachines adapted for processing and transforming electromagnetic signalswhich represent various types of information.

For simplicity only one payment server 110 and mobile wallet application104 are shown but the system may include more payment servers 110 andmobile wallet applications 104 to implement aspects of the workflow forpayment processing described herein. The payment server 110 has at leastone processor, a data storage device (including volatile memory ornon-volatile memory or other data storage elements or a combinationthereof), and at least one communication interface. The payment server110 components may be connected in various ways including directlycoupled, indirectly coupled via a network, and distributed over a widegeographic area and connected via a network (which may be referred to as“cloud computing”).

Although the embodiments have been described in detail, it should beunderstood that various changes, substitutions and alterations can bemade herein without departing from the scope as defined by the appendedclaims.

Moreover, the scope of the present application is not intended to belimited to the particular embodiments of the process, machine,manufacture, composition of matter, means, methods and steps describedin the specification. As one of ordinary skill in the art will readilyappreciate from the disclosure of the present invention, processes,machines, manufacture, compositions of matter, means, methods, or steps,presently existing or later to be developed, that perform substantiallythe same function or achieve substantially the same result as thecorresponding embodiments described herein may be utilized. Accordingly,the appended claims are intended to include within their scope suchprocesses, machines, manufacture, compositions of matter, means,methods, or steps.

As can be understood, the examples described above and illustrated areintended to be exemplary only.

What is claimed is:
 1. A system of processing payment for a transactionat an electronic wallet application on or accessible by a mobile device,comprising: the electronic wallet application having non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing a processor of the mobile device to: authorize a useraccount of the electronic wallet application; trigger the display of aconfirmation request on a display of the mobile device; provide apayment confirmation; a payment server having non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing a processor of the payment server to: associate the useraccount with a first handle for processing payment using the electronicwallet application; receive a payment request to process payment for anelectronic commerce transaction for a merchant website, the paymentrequest indicating the first handle, a merchant identifier andtransaction data; process the payment request to by verifying the useraccount associated with the first handle and the merchant identifierusing a data repository, the user account identifying the electronicwallet application; transmit the confirmation request to the electronicwallet application, the confirmation request including at least aportion of the transaction data; receive the payment confirmation fromthe electronic wallet application; transmit, over a secured channel, apayment security token to a merchant server associated with the merchantwebsite; and transmit an approval message to update the merchant websitewith payment confirmation notification.
 2. The system of claim 1 whereinthe electronic wallet application has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor of the mobile device to generateand transmit a registration request to associate the user account with afirst handle.
 3. The system of claim 1 wherein the first handle isactive to process a single payment request, wherein the payment serveris configured to de-activate the first handle after transmitting thepayment security token.
 4. The system of claim 1 wherein the paymentserver has the non-transitory computer-readable storage medium with thecomputer-executable instructions for causing the processor to process aregistration request to associate the user account with the first handlefor processing payment using the electronic wallet application.
 5. Thesystem of claim 1 wherein the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to receive a first paymentaccount, the first handle for processing payment using the first paymentaccount, and associate the first payment account with the first handle.6. The system of claim 4 wherein the payment server has thenon-transitory computer-readable storage medium with thecomputer-executable instructions for causing the processor to: process asecond registration request to associate the user account with a secondhandle for processing payment using a second payment account; receive asecond payment request to process payment for another electroniccommerce transaction, the payment request indicating the second handle,the merchant identifier or another merchant identifier, and additionaltransaction data; process the payment request to determine the useraccount associated with the second handle; transmit a confirmationrequest including at least a portion of the additional transaction data;authorize the user account of the electronic wallet application; receiveanother payment confirmation from the electronic wallet application toprocess payment using the second payment account; transmit anotherpayment security token to the merchant server associated with themerchant identifier or another merchant server associated with the othermerchant identifier, the other payment security token for the secondpayment account; and transmit an approval message for another paymentconfirmation notification.
 7. The system of claim 1 wherein the paymentserver has the non-transitory computer-readable storage medium with thecomputer-executable instructions for causing the processor to process aregistration request to associate the user account with the first handleby verifying uniqueness of the first handle by determining that thefirst handle is different than all handles of a repository of handlesstored on or accessible by the payment server.
 8. The system of claim 1wherein the payment server has the non-transitory computer-readablestorage medium with the computer-executable instructions for causing theprocessor to generate or identify a unique handle for the first handle,the unique handle being different than all active handles of arepository of handles stored on or accessible by the payment server. 9.The system of claim 1 wherein the payment server has the non-transitorycomputer-readable storage medium with the computer-executableinstructions for causing the processor to generate or identify a timesensitive handle for the first handle, the time sensitive handle beingactive for the electronic commerce transaction only for a defined periodof time.
 10. A payment server for processing payment for a transaction,the payment server connected to an electronic wallet application on oraccessible by a mobile device, the payment server having non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing a processor of the payment server to: associate a useraccount with a first handle for processing payment using the electronicwallet application; receive a payment request to process payment for anelectronic commerce transaction at a merchant website, the paymentrequest indicating the first handle, a merchant identifier andtransaction data; process the payment request to by verifying the useraccount associated with the first handle and the merchant identifierusing a data repository, the user account identifying the electronicwallet application; transmit the confirmation request to the electronicwallet application, the confirmation request including at least aportion of the transaction data; receive the payment confirmation fromthe electronic wallet application; transmit, over a secured channel, apayment security token to a merchant server associated with the merchantwebsite; and transmit an approval message to update the merchant websitewith payment confirmation notification.
 11. The payment server of claim10 having non-transitory computer-readable storage medium withcomputer-executable instructions for causing the processor to receive aregistration request to associate the user account with a first handle.12. The payment server of claim 10 wherein the first handle is active toprocess a single payment request, wherein the payment server isconfigured to de-activate the first handle after transmitting thepayment security token.
 13. The payment server of claim 10 havingnon-transitory computer-readable storage medium with computer-executableinstructions for causing the processor to process a registration requestto associate the user account with the first handle for processingpayment using the electronic wallet application.
 14. The payment serverof claim 10 having non-transitory computer-readable storage medium withcomputer-executable instructions for causing the processor to receive afirst payment account, the first handle for processing payment using thefirst payment account, and associate the first payment account with thefirst handle.
 15. The payment server of claim 13 having non-transitorycomputer-readable storage medium with computer-executable instructionsfor causing the processor to: process a second registration request toassociate the user account with a second handle for processing paymentusing a second payment account; receive a second payment request toprocess payment for another electronic commerce transaction, the paymentrequest indicating the second handle, the merchant identifier or anothermerchant identifier, and additional transaction data; process thepayment request to determine the user account associated with the secondhandle; transmit a confirmation request including at least a portion ofthe additional transaction data; authorize the user account of theelectronic wallet application; receive another payment confirmation fromthe electronic wallet application to process payment using the secondpayment account; transmit another payment security token to the merchantserver associated with the merchant identifier or another merchantserver associated with the other merchant identifier, the other paymentsecurity token for the second payment account; and transmit an approvalmessage for another payment confirmation notification.
 16. The paymentserver of claim 10 having non-transitory computer-readable storagemedium with computer-executable instructions for causing the processorto process a registration request to associate the user account with thefirst handle by verifying uniqueness of the first handle by determiningthat the first handle is different than all handles of a repository ofhandles stored on or accessible by the payment server.
 17. The paymentserver of claim 10 having non-transitory computer-readable storagemedium with computer-executable instructions for causing the processorto generate or identify a unique handle for the first handle, the uniquehandle being different than all active handles of a repository ofhandles stored on or accessible by the payment server.
 18. The paymentserver of claim 10 having non-transitory computer-readable storagemedium with computer-executable instructions for causing the processorto generate or identify a time sensitive handle for the first handle,the time sensitive handle being active for the electronic commercetransaction only for a defined period of time.
 19. The payment server ofclaim 10 having non-transitory computer-readable storage medium withcomputer-executable instructions for causing the processor to process aregistration request to associate the first handle with the mobiledevice and the electronic mobile wallet, and process the payment requestto determine the user account associated with the first handle by:determining the mobile device associated with the first handle, themobile device being associated with the electronic wallet application.20. A method of processing payment for a transaction at an electronicwallet application on or accessible by a mobile device, the methodcomprising: at the mobile device, authorizing a user account of theelectronic wallet application on or accessible by the mobile device;receiving a first handle associated with the user account; receiving aconfirmation request at the electronic wallet application, theconfirmation request for a payment request to process payment for anelectronic commerce transaction at a merchant website, the paymentrequest indicating a first handle, a merchant identifier, andtransaction data; authorizing the user account of the electronic walletapplication; transmitting a payment confirmation to authorise thepayment request to trigger transmission of a payment security token to amerchant server associated with the merchant website; and displaying antransaction message for the payment confirmation.
 21. The method ofclaim 20 further comprising transmitting a registration request toassociate the user account with the first handle for processing paymentusing the electronic wallet application.
 22. The method of claim 20wherein processing the registration request to associate the useraccount with the first handle for processing payment using theelectronic wallet application comprises: receiving a first paymentaccount, the first handle for processing payment using the first paymentaccount.
 23. The method of claim 20 further comprising: at the mobiledevice, authorizing the user account of the electronic walletapplication on or accessible by the mobile device; transmitting a secondregistration request to associate the user account with a second handlefor processing payment using a second payment account; receiving aconfirmation request for a second payment request to process payment foranother electronic commerce transaction, the payment request indicatingthe second handle, the merchant identifier or another merchantidentifier, and additional transaction data; authorizing the useraccount of the electronic wallet application; transmitting anotherpayment confirmation from the electronic wallet application to processpayment using the second payment account to trigger transmission ofanother payment security token to the merchant server associated withthe merchant identifier or another merchant server associated with theother merchant identifier, the other payment security token for thesecond payment account; and transmitting an approval message for anotherpayment confirmation notification.